home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc915.txt < prev    next >
Text File  |  1994-08-01  |  22KB  |  628 lines
  1.  
  2.  
  3. Network Working Group                                       Marc A. Elvy
  4. Request for Comments: 915                             Harvard University
  5.                                                              Rudy Nedved
  6.                                               Carnegie-Mellon University
  7.                                                            December 1984
  8.  
  9.                        NETWORK MAIL PATH SERVICE
  10.  
  11.  
  12. STATUS OF THIS MEMO
  13.  
  14.    This RFC proposes a new service for the ARPA-Internet community and
  15.    requests discussion and suggestions for improvements.  Distribution
  16.    of this memo is unlimited.
  17.  
  18. INTRODUCTION
  19.  
  20.    The network mail path service fills the current need of people to
  21.    determine mailbox addresses for hosts that are not part of the
  22.    ARPA-Internet but can be reached by one or more relay hosts that have
  23.    Unix To Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail,
  24.    etc.
  25.  
  26.    Anyone can use the service if they have TCP/TELNET to one of the
  27.    hosts with a mail path server.
  28.  
  29. DISCUSSION
  30.  
  31.    Currently many hosts that are not connected to the ARPA-Internet
  32.    network can send mail to and receive mail from the ARPA-Internet
  33.    community.  The ARPA-Internet community sends mail using mailbox
  34.    addresses of the form "user@host" or "local-part@domain" [1, 5].  In
  35.    an effort to provide service to hosts not connected directly to the
  36.    ARPA-Internet, mail maintainers have used the feature that the
  37.    "local-part" of the mailbox address is locally interpreted to imbed
  38.    specially encoded mail routing or relaying information.  These
  39.    encoded mailbox addresses have a variety of forms and have become
  40.    common practice. For example:
  41.  
  42.       demco%ucb-ean.cdn%ubc.csnet@CSNET-RELAY.ARPA
  43.  
  44.       "Rudy.Nedved%CMCCTE@CARNEGIE.MAILNET"@MIT-MULTICS.ARPA
  45.  
  46.       ihnp4!cmucsg!ern@UT-SALLY.ARPA
  47.  
  48.       mss.dartmouth@CSNET-RELAY.ARPA
  49.  
  50.       nedved%CMCCTF.BITNET@WISCVM.ARPA
  51.  
  52.    It is important that people be able to communicate, but it is clear
  53.    from the rampant confusion and frustration that something must be
  54.  
  55.  
  56. Elvy & Nedved                                                   [Page 1]
  57.  
  58.  
  59.  
  60. RFC 915                                                       Month Year
  61. Network Mail Path Service
  62.  
  63.  
  64.    provided to make it easier for people to address mail to
  65.    non-ARPA-Internet hosts.  The result, for a variety of reasons, has
  66.    been the work and development of the Domain Name system and
  67.    facilities [2, 3, 7, 9], and it is expected to make mailbox addresses
  68.    be as simple as the current ARPA-Internet mailbox format (e.g.,
  69.    "user@domain").
  70.  
  71.    How do people discover the special encoded addresses for
  72.    non-ARPA-Internet host mailboxes until the domain name system is
  73.    working and covering the majority of hosts in the mail world?  The
  74.    proposed solution to this problem is to provide a network service for
  75.    the ARPA-Internet and a mail service for the non-ARPA-Internet hosts
  76.    that, given a host and an optional addressing system or communication
  77.    protocol or some other piece of information, supplies the mailbox
  78.    address format for sending mail to that host.  For example,
  79.    "nedved@Carnegie.MAILNET" would be translated by the server to
  80.    "nedved%Carnegie.MAILNET@MIT-MULTICS.ARPA". This memo covers the
  81.    proposed network service.
  82.  
  83. DOCUMENT CONVENTIONS
  84.  
  85.    Unless otherwise noted, all numbers are in decimal.
  86.  
  87.    The term "host", as used in this document, describes one computer
  88.    system which may have more than one name associated with it. It may
  89.    have a name for each network or mail connection it supports and may
  90.    have several nicknames or aliases for the computer and/or for each
  91.    set of network names that the computer has acquired.
  92.  
  93. OVERVIEW
  94.  
  95.    The network service is a connection based application on TCP [4].  A
  96.    server listens for TCP connections on the assigned port of 117 [8].
  97.    It responds to the connection with a coded greeting message and waits
  98.    for a command line. For each command line sent to the server, the
  99.    server will respond with a coded message.  The special command QUIT
  100.    causes the server to respond with a coded closing message and closes
  101.    the connection.
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Elvy & Nedved                                                   [Page 2]
  114.  
  115.  
  116.  
  117. RFC 915                                                       Month Year
  118. Network Mail Path Service
  119.  
  120.  
  121. DESIGN GOALS
  122.  
  123.    One of the goals is to provide the service to as many ARPA-Internet
  124.    hosts as possible. In the current ARPA-Internet, experience has shown
  125.    that software people first implement TELNET/TCP [6] before any other
  126.    network application or protocol. Therefore, it is a sub-goal that
  127.    people be able to access the service using available programs (with
  128.    minimal modifications) that implement TELNET/TCP.  Therefore,
  129.    TELNET/TCP on port 117 will work correctly.  The server understands
  130.    TELNET options but refuses all option negotiations that disagree with
  131.    the NVT characteristics defined by the TELNET protocol (see [6]),
  132.    does not echo, and expects command lines to end with <CRLF> (ASCII
  133.    code 13 (octal 15) followed by code 10 (octal 12)).  Character
  134.    echoing and line editing is expected to be handled by the user host
  135.    for the benefit of the user.
  136.  
  137.    Mail systems and other programs are also expected to be able to
  138.    access and understand the service.  Each command reply can have
  139.    multiple line responses with text understandable by the novice user.
  140.    Each command is encoded so as to make it easy for a program to parse
  141.    the lines and extract interesting information, such as whether the
  142.    operation was successful.
  143.  
  144. THE PROTOCOL
  145.  
  146.    Given the developing nature of the protocol and its intent, the
  147.    command lines are composed of a command (case ignored) followed by
  148.    white space, the argument(s) and a <CRLF>. The white space is
  149.    required if any arguments are supplied but the arguments are
  150.    optional.  White space following the command and any optional
  151.    arguments are ignored.
  152.  
  153.       <cmdline> := <cmd> [<WS> <args>] [<WS>] <CRLF>
  154.  
  155.       <WS> := [<WS>] <WS> | <TAB> | <SPACE>
  156.  
  157.    Coded response lines have the rigid format of a 3-digit decimal code
  158.    followed by a space or a dash followed by text composed of characters
  159.    within the ASCII range 32 to 126 (octal 40 to 176) with <CRLF> at the
  160.    end of the line.  The dash after the 3-digit code indicates at least
  161.    one more response line will be supplied while the space indicates the
  162.    current response line is the last one.
  163.  
  164.       <rspline> := <digit><digit><digit><cont><rtext><CRLF>
  165.  
  166.       <cont> := <SPACE> | "-"
  167.  
  168.  
  169.  
  170. Elvy & Nedved                                                   [Page 3]
  171.  
  172.  
  173.  
  174. RFC 915                                                       Month Year
  175. Network Mail Path Service
  176.  
  177.  
  178.       <rtext> := ASCII characters in the range 32 to 126.
  179.  
  180.    Some of the successful response text to certain commands have rigid
  181.    formats so programs can extract path information. The commands that
  182.    have format restrictions are clearly noted and the response format is
  183.    documented with the command.
  184.  
  185.    The response codes are in the range from 200 to 599 inclusively. The
  186.    following paragraphs provide the break down for each digit.
  187.  
  188.    The first, most significant, digit is the success indicator. It
  189.    breaks down into the simple success and total failure responses but
  190.    includes the ability to communicate a temporary failure condition and
  191.    the need for further information that has worked so well for SMTP [5]
  192.    and other similiar protocols.  The codes are:
  193.  
  194.       2xx  Positive reply.
  195.  
  196.       3xx  Intermedate reply. Positive acknowlegement but more
  197.            information is neccessary.
  198.  
  199.       4xx  Temporary error. Try again later.
  200.  
  201.       5xx  Permanent error. Do not retry.
  202.  
  203.    The second digit is used to classify the response to provide a flavor
  204.    for certain types of success. The flavor is apparent in providing the
  205.    response on whether a host name is known by a domain name server or
  206.    not. The codes are:
  207.  
  208.       x0x  Command related response.
  209.  
  210.       x1x  Connection related response.
  211.  
  212.       x2x  Database related response.
  213.  
  214.       x3x  Domain transition related response.
  215.  
  216.       x4x  Data added response.
  217.  
  218.       x5x  Data deleted response.
  219.  
  220.       x6x  Data modified response.
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227. Elvy & Nedved                                                   [Page 4]
  228.  
  229.  
  230.  
  231. RFC 915                                                       Month Year
  232. Network Mail Path Service
  233.  
  234.  
  235. BASIC IMPLEMENTATION
  236.  
  237.    The minimum implementation is the support of three commands: HELP,
  238.    PATH and QUIT. The HELP command provides some level of documentation
  239.    and possibly lists the known addressing or communication protocols.
  240.    The PATH command takes as a required argument a user name or id
  241.    followed by a "@", followed by a domain style host name whose domain
  242.    components may be an addressing protocol, a communication
  243.    environment, or an unofficial or colloquial domain.
  244.  
  245.       S: (server listens on port 117)
  246.       U: (user connects to port 117)
  247.       S: 210-Welcome to the CMU network mail path service.
  248.       S: 210 Type 'HELP' for help.
  249.       U: help
  250.       S: 200-The server currently knows about the following mail worlds:
  251.       S: 200-    BITNET,UUCP,CSNET,.AC.UK,EARNET,JANET,CDNNET
  252.       S: 200-Use the PATH command with "user@host.world" to get the
  253.       S: 200 ARPA-Internet mail address.
  254.       U: path root@inria.uucp
  255.       S: 220 philabs!mcvax!inria!root@SEISMO.ARPA
  256.       U: quit
  257.       S: 211 Bye bye.
  258.       S: (server closes connection)
  259.  
  260. DETAILED PROTOCOL DESCRIPTION
  261.  
  262.    The protocol is designed to provide a flexible but conservative
  263.    mechanism for providing responses and adding experimental or extended
  264.    commands.
  265.  
  266.       <user connects to server>
  267.  
  268.          The server responds with a message indicating the status of the
  269.          server and optional information.
  270.  
  271.             210  Greeting message indicating the server is ready.
  272.  
  273.             410  The server is down for some unknown reason for a short
  274.                  time.
  275.  
  276.             510  The server is unavailable.
  277.  
  278.       HELP [<arg>]
  279.  
  280.          The server can respond with general help information about the
  281.          server, about the specific topic described by "arg", or it can
  282.  
  283.  
  284. Elvy & Nedved                                                   [Page 5]
  285.  
  286.  
  287.  
  288. RFC 915                                                       Month Year
  289. Network Mail Path Service
  290.  
  291.  
  292.          indicate that something is temporarily wrong with the HELP
  293.          facility.  It is strongly recomended that the general HELP
  294.          command documentation be implemented and expanded.
  295.  
  296.             200  General or specific documentation given.
  297.  
  298.             220  Documentation given from a database.
  299.  
  300.             421  Service temporarily unavailable.
  301.  
  302.             501  Command not implemented or topic not known.
  303.  
  304.       PATH <user>@<host>
  305.  
  306.          The server normally responds with either the mail path that
  307.          will work for the given mailbox address or indicates the domain
  308.          style host name is unknown. If the database is in transition or
  309.          inconsistent, a temporary or permanent error can be supplied.
  310.  
  311.             220  Rigid format route given.
  312.  
  313.             230  Rigid format route given. Domain servers should be
  314.                  used.
  315.  
  316.             420  Database problems. Try again later.
  317.  
  318.             501  Invalid argument form or null argument given.
  319.  
  320.             520  No such host found in database.
  321.  
  322.             521  Host name is ambiguous.
  323.  
  324.       When a route is supplied with the 2xx success responses. It has a
  325.       fixed format with a one-line response. The format is as follows:
  326.  
  327.          <3-digit-code><SP><local-part>@<domain><CRLF>
  328.  
  329.       The "local-part" and "domain" components are defined under the
  330.       SMTP protocol [5] and are intended to be used over SMTP
  331.       connections.
  332.  
  333.       QUIT
  334.  
  335.          Respond and close the server down.
  336.  
  337.             211  Close the connection down.
  338.  
  339.  
  340.  
  341. Elvy & Nedved                                                   [Page 6]
  342.  
  343.  
  344.  
  345. RFC 915                                                       Month Year
  346. Network Mail Path Service
  347.  
  348.  
  349.    One special code is reserved and is used for a special case. The code
  350.    is 412 and is sent when the server has been waiting for a response
  351.    for more then 2 minutes and has decided to timeout the connection.
  352.    After the "412 <timeout msg>" is sent, the server may close or
  353.    possibly abort the connection.
  354.  
  355.    Because of the somewhat experimental nature of the server, additional
  356.    commands are expected to be added as they become needed. No
  357.    restrictions are placed on the names of these experimental commands
  358.    other then the must not conflict with the basic commands and are not
  359.    allowed to be abbreviated (i.e., "SEAR" can not be used for
  360.    "SEARCH").
  361.  
  362. PATH COMMAND ARGUMENTS
  363.  
  364.    It is important to understand that the server is an aid to users that
  365.    may have minimal amount of information about the host. Therefore the
  366.    PATH command takes domain style host names that may be complete or
  367.    incomplete specifications for the host and may be common or
  368.    colloquial domain names. The servers look through the entire database
  369.    for anything that matches and try to find the best answer
  370.    disregarding any local domain information.  If several hosts have the
  371.    same nickname or alias and lack distinguishing domain components, the
  372.    server returns an error response containing all of the hosts found.
  373.    Some implementation may even break down the host name and indicate in
  374.    error messages that even though it did not find the host, it found
  375.    something else that might be what the user wanted.
  376.  
  377. MAIL PATH SERVICE AND DOMAINS
  378.  
  379.    As mentioned previously, the mail path service is not intended to be
  380.    a replacement or a parallel service to the domain name system.  It is
  381.    a stop gap measure and, when most of the domain name system is in
  382.    place, will probably be disabled on some or most of the hosts with
  383.    the service.
  384.  
  385.    Mail systems should check the domain name servers for the specified
  386.    host before trying a mail path server. The mail path servers should
  387.    be modified when one or more domain servers are in place to check if
  388.    a host is part of the domain system and to generate an error or an
  389.    indication (but still include the path information) if a host is
  390.    found to be a part of the domain system.
  391.  
  392.    The names used by the mail path servers have no official standing in
  393.    the ARPA-Internet community and have colloquial origins. The domain
  394.    name components are based on the adminstrative entities involved
  395.    whereas many of the current unofficial common domain style names for
  396.  
  397.  
  398. Elvy & Nedved                                                   [Page 7]
  399.  
  400.  
  401.  
  402. RFC 915                                                       Month Year
  403. Network Mail Path Service
  404.  
  405.  
  406.    non-ARPA-Internet hosts are based on the protocol used, the relay
  407.    host used, or some acronym that someone dreamed up.  Only a few of
  408.    the current domain style names that are privately in use are expected
  409.    to be used by the ARPA-Internet community when the domain name
  410.    service is in use by the majority of the ARPA-Internet community.
  411.  
  412. CAVEATS
  413.  
  414.    The greatest problem with the new service, as implemented, is that it
  415.    reports paths from the service host rather than from the user's host.
  416.    This is due to the nature of software.  It would be more convenient
  417.    if it reported a correct path from the caller's host, but this would
  418.    require a different method of database management (a method which
  419.    could quickly compute the path from the caller's machine or a machine
  420.    which would be willing to keep updated databases for each host (which
  421.    is impractical)).
  422.  
  423.    Two minor problems exist with the database used by the software. Many
  424.    relay hosts exist in several different protocol or addressing name
  425.    spaces but under different names. The current software cross
  426.    referencing for the multiple protocol relay hosts is done by hand,
  427.    but, given the seeming reliability of these relay hosts, the problem
  428.    does not appear to be significant.  The second problem is that the
  429.    data should be collected from the actual relay hosts to ensure
  430.    correctness, but in many cases this is impossible.
  431.  
  432. EXAMPLES
  433.  
  434.    Find a route to CMU-CC-TE in the CARNEGIE part of MAILNET for user id
  435.    EN0C:
  436.  
  437.       S: (server listens on port 117)
  438.       U: (user connects to port 117)
  439.       S: 210-Welcome to the CMU network mail path service
  440.       S: 210 Type 'HELP' for help.
  441.       U: path EN0C@CMU-CC-TE.CARNEGIE.MAILNET
  442.       S: 220 EN0C%CMU-CC-TE%CARNEGIE.MAILNET@MIT-MULTICS.ARPA
  443.       U: quit
  444.       S: 211 Bye bye.
  445.       S: (server closes connection)
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455. Elvy & Nedved                                                   [Page 8]
  456.  
  457.  
  458.  
  459. RFC 915                                                       Month Year
  460. Network Mail Path Service
  461.  
  462.  
  463.    Find a route to a host which has an unknown addressing system or
  464.    communication protocol and for which the name may be an alias:
  465.  
  466.       S: (server listens on port 117)
  467.       U: (user connects to port 117)
  468.       S: 210-Welcome to the CMU network mail path service
  469.       S: 210 Type 'HELP' for help.
  470.       U: path mss@dartvax
  471.       S: 220 mss%dartmouth@CSNET-RELAY.ARPA
  472.       U: quit
  473.       S: 211 Bye bye.
  474.       S: (server closes connection)
  475.  
  476.    Find a route to a host that is known by a very long domain style name
  477.    but is not in the current ARPA-Internet host tables:
  478.  
  479.       S: (server listens on port 117)
  480.       U: (user connects to port 117)
  481.       S: 210-Welcome to the CMU network mail path service
  482.       S: 210 Type 'HELP' for help.
  483.       U: path rob@vax1.cent.lanc.ac.uk
  484.       S: 220 rob%vax1.cent.lanc@UCL-CS.ARPA
  485.       U: quit
  486.       S: 211 Bye bye.
  487.       S: (server closes connection)
  488.  
  489.    Find a route to a host without any additional information and the
  490.    name is discovered to be ambiguous:
  491.  
  492.       S: (server listens on port 117)
  493.       U: (user connects to port 117)
  494.       S: 210-Welcome to the CMU network mail path service
  495.       S: 210 Type 'HELP' for help.
  496.       U: path brad@pitt
  497.       S: 521-Several hosts found under the name of 'pitt', try one of:
  498.       S: 521-brad@pitt.UUCP
  499.       S: 521-brad@pitt.CSNET
  500.       U: path brad@pitt.CSNET
  501.       S: 220 brad%pitt@CSNET-RELAY.ARPA
  502.       U: quit
  503.       S: 211 Bye bye.
  504.       S: (server closes connection)
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512. Elvy & Nedved                                                   [Page 9]
  513.  
  514.  
  515.  
  516. RFC 915                                                       Month Year
  517. Network Mail Path Service
  518.  
  519.  
  520. ACKNOWLEDGEMENTS
  521.  
  522.    The original protocol was documented by Marc Elvy for a server that
  523.    he and Alan Langerman built.  The server used the pathalias software
  524.    created by Steve Bellovin, as modified by Peter Honeyman and Robert
  525.    T. Morris, to maintain the host to host connection database.  The
  526.    software provided a way for people to make sense out of the jungle of
  527.    UUCP hosts. The Info-Nets@MIT-MC mailing list, created and maintained
  528.    by Robert Krawitz, made the CMU and Harvard mail path projects aware
  529.    of each other and the people on the list provided many of the mail
  530.    relay databases that are in use by the mail path servers.  The
  531.    original server may be accessed through TCP port 117 on harvard.arpa
  532.    -- the "pathto" program that runs under 4.2BSD UNIX may be obtained
  533.    as a front end to the server from RFC915@HARVARD.ARPA.
  534.  
  535.    The current protocol scope was changed by Rudy Nedved to cover
  536.    BITNET, CSNET, MAILNET and other "mail networks" and further refined
  537.    by Marc Elvy, Alan Langerman and others.
  538.  
  539.    Comments should be sent to RFC-915@HARVARD.ARPA or mailed (via the
  540.    U.S.  Postal Service) to:
  541.  
  542.       Marc A. Elvy
  543.       108 Aiken Computation Laboratory
  544.       33 Oxford Street
  545.       Harvard University
  546.       Cambridge, MA 02138
  547.  
  548.       (617) 495-5849
  549.  
  550.       Rudy Nedved
  551.       Department of Computer Science
  552.       Carnegie-Mellon University
  553.       Schenley Park
  554.       Pittsburgh, PA 15213
  555.  
  556.       (412) 578-7685
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569. Elvy & Nedved                                                  [Page 10]
  570.  
  571.  
  572.  
  573. RFC 915                                                       Month Year
  574. Network Mail Path Service
  575.  
  576.  
  577. REFERENCES
  578.  
  579.    [1]   Crocker, D. "Standard for the Format of ARPA Internet Text
  580.          Messages". RFC 822, Department of Electrical Engineering,
  581.          University of Delaware, August, 1982.
  582.  
  583.    [2]   Mockapetris, P. "Domain Names - Concepts and Facilities".
  584.          RFC 882, USC/Information Sciences Institute, Novemeber, 1983.
  585.  
  586.    [3]   Mockapetris, P. "Domain Names - Implementation Specification".
  587.          RFC 883, USC/Information Sciences Institute, Novemeber, 1983.
  588.  
  589.    [4]   Postel, J. "Transmission Control Protocol- DARPA Internet
  590.          Program Protocol Specification". RFC 793, USC/Information
  591.          Sciences Institute, September, 1981.
  592.  
  593.    [5]   Postel, J. "Simple Mail Transfer Prootcol". RFC 821,
  594.          USC/Information Sciences Institute, August, 1982.
  595.  
  596.    [6]   Postel, J., and J. Reynolds. "Telnet Protocol Specification".
  597.          RFC 854, USC/Information Sciences Institute, May, 1983.
  598.  
  599.    [7]   Postel, J. "Domain Name System Implementation Schedule".
  600.          RFC 897, USC/Information Sciences Institute, Feburary, 1984.
  601.  
  602.    [8]   Reynolds, J., and J. Postel. "Assigned Numbers". RFC 923,
  603.          USC/Information Sciences Institute, October, 1984.
  604.  
  605.    [9]   Su, Z., and Postel, J. "The Domain Naming Convention for
  606.          Internet User Applications". RFC 819, SRI International,
  607.          August, 1982.
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626. Elvy & Nedved                                                  [Page 11]
  627.  
  628.